Cloud-mediated vehicle notification exchange for localized transit events

ABSTRACT

Vehicles in transit within a location may transmit and/or receive information about transit events arising within the location, such as accidents, developing weather, and road obstructions. Because localized exchange channels, such as a radiofrequency broadcast, may be range-limited and/or unreliable, a centralized service may be provided to facilitate the exchange of notifications about transit events, but it may be difficult to provide a centralized service that is both scalable to millions of vehicles and capable of low-latency exchange of time-sensitive notifications for transit events. The techniques presented herein provide an architecture for broadcasting transit events through a transit service that maintains vehicle area groups, respectively identifying the vehicles that are associated with each location. The service may receive a notification of a transit event for a location, and may utilize the vehicle area group for the location to broadcast the notification to the other vehicles of the area group.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority under 35 U.S.C. §119(e) to U.S. Patent Application No. 61/946,962, filed on Mar. 3, 2014, the entirety of which is incorporated by reference as if fully rewritten herein.

BACKGROUND

Within the field of computing, many scenarios involve devices that inform and assist a user within a vehicle, e.g., by autonomously navigating the vehicle, and/or presenting transit-related information to a driver of the vehicle. In such scenarios, transit events may arise that relate to a current location and/or a current route of the vehicle, such as a traffic accident; developing traffic congestion; road obstructions, such as debris or wildlife present in a lane of the road; and weather-related conditions, such as ice or flooding. Various techniques may be utilized to notify the user and/or adjust the autonomous control of the vehicle in response to such transit events.

SUMMARY

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key factors or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Many techniques may be utilized to exchange messages about transit events, such as events that may be related to or have an impact on a roadway network of a city. As a first such example, a notification of a transit event may be broadcast over a localized broadcast channel, such as a radiofrequency that encodes a voice message that can be played for the user of the message, or a digital signal that encodes a message for the device of the vehicle. As a second such example, vehicles may locally communicate with one another using a wireless communication channel, such as localized Wi-Fi or Dedicated Short-Range Communication (DSRC) message broadcast. As a third such example, a centralized service may communicate with vehicles over a long-distance channel, such as the internet, and may coordinate the delivery of notifications, such as a weather service that monitors the transit of enrolled vehicles and transmits transit-related weather information to the vehicles.

While many such techniques may be devised, several considerations of such techniques may limit the utility of such techniques. As a first such example, localized broadcast channels are often subject to interference, crosstalk, jamming, spoofing, and interception by unintended third parties. As a second such example, vehicle-to-vehicle communication may be limited by range broadcast restrictions, and may have difficulty scaling to accommodate messaging among a large number of vehicles. As a third such example, communication mediated by a remote server may exhibit a large amount of latency, which may be problematic for the timely delivery of urgent transit event notifications; e.g., it may be difficult to provide a remote server that is capable of scaling to handle potentially millions of vehicles, and also capable of exchanging transit event notifications among such vehicles in a low-latency manner

Presented herein are techniques for exchanging notifications of transit events among vehicle using a transit service. Such techniques involve an architecture where the transit service maintains a set of vehicle area groups, each identifying the vehicles that are associated with each location. When a vehicle reports a particular location (e.g., a set of global positioning service (GPS) coordinates), the transit service may add the vehicle to the vehicle area group for the location (e.g., a vehicle area group for a portion of a geographic region that includes the reported GPS coordinate). The locations may be defined statically, e.g., as a set of GPS coordinates defining a boundary of a region, or dynamically, e.g., as the site of an event that impacts transit, or an area of traffic congestion. When the transit service receives a notification of a transit event from a vehicle within a particular location, the transit service may identify a current or a dynamically predicted vehicle area group of the vehicle, or may create such a vehicle area group for the vehicle if one does not exist. The transit service may also identify the other vehicles of the vehicle area group; and may broadcast the notification to the other vehicles of the vehicle area group. As one such example, the server may utilize a websockets architecture, wherein the devices of the respective vehicles connect to the transit service via a websocket that is maintained open and alive without having to exchange keepalive or “ping” messages. The server may receive transit events about a location from a vehicle of the vehicle area group for the location, and may transmit notifications of such transit events to the other vehicles of the vehicle area group via the websockets allocated for each such vehicle. In this manner, the transit service may efficiently and rapidly exchange transit event notifications among the vehicles of the location in accordance with the techniques presented herein.

To the accomplishment of the foregoing and related ends, the following description and annexed drawings set forth certain illustrative aspects and implementations. These are indicative of but a few of the various ways in which one or more aspects may be employed. Other aspects, advantages, and novel features of the disclosure will become apparent from the following detailed description when considered in conjunction with the annexed drawings.

DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of an example scenario featuring various techniques for broadcasting notifications about transit events for a location.

FIG. 2 is an illustration of an example scenario featuring an architecture for broadcasting notifications about transit events for a location in accordance with the techniques presented herein.

FIG. 3 is an illustration of an example method of broadcasting notifications about transit events for a location, in accordance with the techniques presented herein.

FIG. 4 is an illustration of a first example system for broadcasting notifications about transit events for a location, in accordance with the techniques presented herein.

FIG. 5 is an illustration of a second example system for broadcasting notifications about transit events for a location, in accordance with the techniques presented herein.

FIG. 6 is an illustration of an example computer-readable medium comprising processor-executable instructions configured to embody one or more of the provisions set forth herein.

FIG. 7 is an illustration of a first example technique for detecting transit events arising within a location, in accordance with the techniques presented herein.

FIG. 8 is an illustration of a second example technique for detecting transit events arising within a location, in accordance with the techniques presented herein.

FIG. 9 is an illustration of an example technique for rebroadcasting transit events arising within a location, in accordance with the techniques presented herein.

FIG. 10 is an illustration of an example technique for broadcasting notifications of transit events to several vehicle area groups, in accordance with the techniques presented herein.

FIG. 11 is an illustration of an example technique for notifying a user about a transit event for a location, in accordance with the techniques presented herein.

FIG. 12 is an illustration of an example computing environment wherein one or more of the provisions set forth herein may be implemented.

DETAILED DESCRIPTION

The claimed subject matter is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the claimed subject matter. It may be evident, however, that the claimed subject matter may be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to facilitate describing the claimed subject matter.

A. Introduction

FIG. 1 is an illustration of an example scenario 100 featuring a user 102 of a vehicle 104 operated in an area 108, such as a span of a road, alongside other vehicles 104 operated by drivers 106. In this example scenario 100, a transit event 110 may occur, such as a vehicular accident between two vehicles 104, that interferes with transit in the area 108. A variety of such transit events 110 may arise, such as obstructions to transit through the area 108 (e.g., the development of traffic congestion due to heavy vehicular volume, construction, or a failure of traffic signals; debris or wildlife located in a lane of the road; or weather-related events, such as flooding or the formation of ice on the road).

It may be desirable to transmit a notification of the transit events 110 to the user 102 and the other drivers 106 of such vehicles 104, as such notification may alert them to the transit event 110 as a safety precaution, and/or enable the user 102 and other drivers 106 to choose an alternate route that avoids the area 108. Many techniques may be devised to distribute such notification of transit events 110, some of which are illustrated in the example scenario 100 of FIG. 1.

As a first such example 122, information about the transit event 110 may be broadcast by a regional broadcast tower 112 using a local broadcast messaging channel, such as a selected radiofrequency over which messages may be encoded and broadcast at high power to reach a large region. Such messages may be distributed, e.g., as human-perceivable audio messages that are received by a radio within each vehicle 104; encoded text messages that are received by a device with a text display for presentation to the user 102 and drivers 106 of the vehicles 104; and/or encoded signals to be received and interpreted by an autonomous control system of the vehicle 104. For example, a regional broadcast service may transmit notifications 114 over a traffic message channel (TMS) of all transit events 110 occurring throughout the region including the area 108, such as construction, vehicular accidents, and/or traffic congestion.

As a second such example 124, a first vehicle 104 may include a sensor that detects a transit event 110 such as a vehicular accident, and a vehicle-to-vehicle communication device comprising a transmitter 116 that detects the transit event 110 and transmits a notification 114 to a receiver 120 on board the vehicle 104 of the user 102 through a localized messaging channel, such as a low-broadcast radiofrequency (RF) channel, using a protocol such as Wi-Fi. The transmitter 120 may receive the notification 114 and utilize it in various ways, such as notifying the user 102 or adjusting an autonomous control system (e.g., reducing a cruise control speed, or engaging emergency braking). In this manner, various techniques may be utilized to exchange notifications 114 of transit events 110 to the drivers 106 of vehicles 104 and users 102 on board vehicles 104 in the area 108.

However, some disadvantages may arise within such techniques that affect the distribution of such notifications 114.

As a first such example, a regional broadcast tower 112 may broadcast a set of notifications 114 applicable throughout the region, but such broadcasting may be nonspecific, and may include information that is not applicable to some, and possibly a large proportion, of the receivers including the user 102 and other drivers 106. For example, in the first example 122 of FIG. 1, the regional broadcast tower 112 encodes the transit event 110 for the area 108, but also includes information about a second transit event 110 that occurs in a distant area 108, and is likely not relevant to the user 102 or the other drivers 106. The inclusion of extraneous information may desensitize the user 102 and/or other drivers 106 to the provided information, who may then miss the notification 114 of the transit event 110 that is relevant to their transit. Moreover, the provision of the regional broadcast tower 112 to provide notifications 114 for all transit events 110 within a large region may delay the delivery of a time-sensitive notification 114; e.g., it may be desirable to distribute a notification 114 of the vehicular accident to the user 102 and drivers 106 of the area 108 as quickly as possible, but if the notification 114 is one of a dozen such notifications for an entire region, the delivery may be delayed and may fail to present the notification in time for the user 102, other drivers 106, and autonomous control systems of the vehicles 104 to react.

As a second such example, the localized vehicle-to-vehicle transmission as illustrated in the second example 124 may be more localized and selective than the regional broadcast tower 112, but its utility may be limited by a variety of factors. For example, broadcast restrictions on localized broadcast messaging channels (e.g., federal regulations on the maximum power of unlicensed radiofrequency transmissions) may reduce the power and range with which the transmitter 116 may transmit the notification 114, causing vehicles 104 that are outside of the range of the low-powered transmitter 116 not to receive the notification 114. For example, in a high-speed environment such as a highway, it may be desirable to transmit the notification 114 to vehicles 104 over a hundred meters away, but the transmitter 116 may have a restricted range of twenty meters. Moreover, low-power localized broadcast messaging channels may be unreliable due to a variety of factors, such as interference, crosstalk with other applications, jamming, spoofing, and/or interception by unintended individuals. For example a vehicle-to-vehicle communication system is unlikely to be effective for exchanging a large number of messages 114 among a large population of transmitters 116 (e.g., traffic congestion may feature hundreds of vehicles 104 that are attempting to transmit notifications 114 concurrently to hundreds of other vehicles 104, and the continuous exchange of notifications 114 over the same range of localized broadcast messaging channels may severely limit the successful delivery of such notifications 114).

Due to these difficulties with localized exchange of notifications 114, other techniques may be utilized. For example, a remote server may receive notifications 114 of transit events 110, and may rebroadcast such notifications 114 to vehicles 114 within a particular area 108. However, the architecture of such centralized services may affect the capabilities of such broadcast notification systems. In particular, a remote server may be tasked with exchanging messages 114 among millions of vehicles 104, and may therefore incur latency in achieving such delivery, e.g, while figuring out the subset of the millions of vehicles 104 is to receive the notification 114. Such latency may not be a significant issue with other scenarios, such as email messages and text messages, where latency of several seconds may be acceptable and not even noticeable; however, in the context of exchanging potentially urgent messages among vehicles 104, latency may significantly reduce the value of the transit service. These and other complications may arise within various techniques for distributing notifications 114 among the vehicles 104 of a location 102.

B. Presented Techniques

FIG. 2 is an illustration of an example scenario 200 featuring techniques for exchanging notifications 114 of transit events 110 among the users 102, drivers 106, and vehicles 104 of an area 108.

In this example scenario 200, a transit service 202 is provided that is in communication with devices aboard the vehicles 104 traveling in the area 108, and may participate in the exchange of notifications of transit events 110 in the area 108 that affect such vehicles 104. In particular, the transit service 202 associates the respective vehicles 104 within the area 108 with a particular location 204, such as a defined span of a highway (e.g., between specified kilometer markers). For the respective locations 204, the transit service 202 may create a vehicle area group 206 identifying the vehicles 104 that are in transit within the location 204. For example, the respective vehicles 104 may report to the transit service 202 a current location of the vehicle 104, such as a global positioning system (GPS) coordinate, and the transit service 202 may determine the location 204 encompassing the current location of the vehicle 104, and then add the vehicle 104 to the vehicle area group 206 for the location 204. A transit event 110 may arise that is detected by a device on board a vehicle 104, which transmits a notification 208 of the transit event 110 to the transit service 202. The transit service 202 may identify the vehicle area group 206 of the vehicle 106 reporting the transit event 110, and the other vehicles 104 of the vehicle area group 206. The transit service 202 may then broadcast a notification 210 of the transit event 110 to the other vehicles 104 within the vehicle area group 206 for the location 204. For example, in the example scenario 200 of FIG. 2, the transit event 110 may be relevant to a subset of the vehicles 104 communicating with the transit service 202 (e.g., vehicles 1, 2, and 3, wherein vehicle 3 reports the transit event 110 to the transit service 202), and not relevant to other vehicles 104 that are farther away from the site of the transit event 110, such as vehicles 4 and 5. Accordingly, the transit service 202 may selectively broadcast the notification 210 to vehicles 1 and 2, and may refrain from broadcasting the notification 210 to vehicle 3 (which initiated the notification 208 of the transit event 110) and/or vehicles 4 and 5 (which are not in the same vehicle area group 206). In this manner, the transit service 110 may utilize a cloud-based architecture for broadcasting notifications 210 of transit events 110 to the vehicles 104 of the location 204 affected by the transit event 110, and may do so by utilizing the pre-formed vehicle area group 206 that identifies such vehicles 104, in accordance with the techniques presented herein.

C. Technical Effects

The techniques presented herein may provide a variety of technical effects in the scenarios provided herein.

As a first such example, the techniques provided herein may enable a more reliable transmission of notifications 210 of transit events 110 to the vehicles 104 with the location 204 affected by the transit event 110 than localized broadcast message channels, which may be limited by such factors as range restrictions and interference. For example, the techniques presented herein may utilize an internet connection of a mobile device for the exchange of notifications 210, and internet connectivity may be both more well-developed and more ubiquitous than specialized equipment and support for a localized broadcast message channel such as traffic messaging systems (TMS).

As a second such example, the techniques provided herein may enable greater selectivity of the transmission of notifications 210, i.e., limiting the transmission of notifications 210 to the vehicles 104 that are affected by the transit event 110. Such selectivity may raise the signal-to-noise ratio of the notification system; may conserve the computational and messaging resources utilized in such delivery; and/or may enable faster delivery of such notifications 210 (e.g., by avoiding circumstances where the transmission of a first notification 210 that is relevant to the vehicles 104 in a particular location 204 is delayed by the transmission of a second notification 210 that does not apply to the vehicles 104 or the location 204).

As a third such example, the techniques provided herein may scale to support a large number of vehicles 104 and/or transit events 106, without incurring scalability penalties such as latency. A transit service 202 that receives a notification 208 and may utilize readily-available vehicle area groups 206 to determine the other vehicles 104 that are to receive the broadcast notification 210 may achieve such delivery faster than a transit service 202 that, ad-hoc, identifies the vehicles 104 to receive the broadcast notification 210 among a potentially large set of millions of vehicles 104. Many such technical effects may arise from the broadcasting of notifications 210 of transit events 110 in accordance with the techniques presented herein.

D. Example Embodiments

FIG. 3 presents a first example embodiment of the techniques presented herein, illustrated as an example method 300 of broadcasting localized transit events 110 detected during transit of a vehicle 104. The example method 300 may be implemented on a device having a processor, and that is in communication with a transit service 202 having information about the locations 206 of the area 108. The example method 300 may be implemented, e.g., as a set of instructions stored in a memory component of the device (e.g., a memory circuit, a platter of a hard disk drive, a solid-state memory component, or a magnetic or optical disc) that, when executed by the processor of the device, cause the device to perform the techniques presented herein.

The example method 300 begins at 302 and involves executing 304 the instructions on the processor. Specifically, the instructions cause the device to detect 306 a location 204 of the vehicle 104. The instructions also cause the device to transmit the location 204 to the transit service 202 to add the vehicle 104 to a vehicle area group 206 for the location 204. The instructions also cause the device to, upon detecting a transit event 110 in the location 204 of the vehicle 104, transmit 310 the transit event 110 to the transit service 202 for broadcasting to other vehicles 104 of the vehicle area group 206. The instructions also cause the device to, upon receiving from the transit service 202 a notification 210 of a transit event 110 for the vehicle area group 206, utilize 312 the notification 210 in the transit of the vehicle 104. In this manner, the example method 300 enables the vehicle 104 to participate in the exchange of notifications 210 about the transit events 110 arising within the area 108 through interaction with a travel service 202 provided in accordance with the techniques presented herein, and so ends at 314.

FIG. 4 presents an illustration of an example scenario 400 featuring a second example embodiment of the techniques presented herein, illustrated as an example server 402 comprising a system 410 that provides a transit service 202 to a set of vehicles 104. The example system 410 may be implemented, e.g., on a server 402 having a processor 404, a memory 408, and a vehicle communicator 406 that communicates with the vehicles 104. A portion of the server 402 and/or traffic service 202 may be located within the vehicle 104 of the user 102, and/or may be located at a remote location. Respective components of the example system 410 may be implemented, e.g., as a set of instructions stored in a memory 408 of the server 402 and executable on the processor 404 of the server 402, such that the interoperation of the components causes the server 402 to operate according to the techniques presented herein.

The example system 410 comprises a vehicle area group manager 412, which, upon receiving a location 204 of a vehicle 104, adds the vehicle 104 to a vehicle area group 210 for the location 204. The system 410 also comprises a transit event broadcaster 414, which, upon receiving, from a vehicle 104, a notification 208 of a transit event 110 for the location 204, identifies at least one other vehicle 104 of the vehicle area group 206, and broadcasts to the at least one other vehicle 104 of the vehicle area group 206 a notification 210 of the transit event 110. In this manner, the example system 410 provides a travel service 202 that facilitates the exchange of notifications 210 about the transit events 110 of the location 204 in accordance with the techniques presented herein.

FIG. 5 presents an illustration of an example scenario 500 featuring a third example embodiment of the techniques presented herein, illustrated as an example vehicle device 502 featuring an example system 514 that enables a vehicle 104 to exchange notifications 210 with other vehicles 104 about transit events 110 arising in the location 204 of the vehicles 104. The example system 514 may be implemented, e.g., on a vehicle device 502 having a processor 504; a memory 512; a location detector 506 that detects a location 204 of the vehicle 104 (e.g., a global positioning system (GPS) coordinate); a transit service communicator 508 that communicates with a transit service 202 (e.g., a wireless network adapter that is connected to the transit service 202 via an internet connection); and a transit event detector 510 that detects a transit event 110 in the location 204 of the vehicle 104. Respective components of the example system 514 may be implemented, e.g., as a set of instructions stored in the memory 512 of the vehicle device 502 and executable on the processor 504 of the vehicle device 502, such that the interoperation of the components causes the vehicle device 502 to operate according to the techniques presented herein.

The example system 514 comprises a transit service interface, which transmits the location 204 of the vehicle 104, via the transit service communicator 508, to the transit service 202 in order to add the vehicle 104 to a vehicle area group 206 for the location 204, and also transmits to the transit servicer 202, via the transit service communicator 508, a notification 208 of the transit event 110 for broadcasting to other vehicles 104 of the vehicle area group 206. The example system 514 also comprises a local event notifier 518, which, upon receiving from the transit service 202 a notification 210 of a transit event 110 for the vehicle area group 206, utilizes the notification 210 in the transit of the vehicle 104 (e.g., by presenting the notification 210 to the user 102; by adjusting an autonomous control system of the vehicle 104; and/or by adjusting a route selected by the user 102 to reach a destination). In this manner, the example system 514 may enable the vehicle device 502 to exchange notifications 210 about the transit events 110 arising within the location 204 in accordance with the techniques presented herein.

Still another embodiment involves a computer-readable medium comprising processor-executable instructions configured to apply the techniques presented herein. Such computer-readable media may include, e.g., computer-readable storage media involving a tangible device, such as a memory semiconductor (e.g., a semiconductor utilizing static random access memory (SRAM), dynamic random access memory (DRAM), and/or synchronous dynamic random access memory (SDRAM) technologies), a platter of a hard disk drive, a flash memory device, or a magnetic or optical disc (such as a CD-R, DVD-R, or floppy disc), encoding a set of computer-readable instructions that, when executed by a processor of a device, cause the device to implement the techniques presented herein. Such computer-readable media may also include (as a class of technologies that are distinct from computer-readable storage media) various types of communications media, such as a signal that may be propagated through various physical phenomena (e.g., an electromagnetic signal, a sound wave signal, or an optical signal) and in various wired scenarios (e.g., via an Ethernet or fiber optic cable) and/or wireless scenarios (e.g., a wireless local area network (WLAN) such as WiFi, a personal area network (PAN) such as Bluetooth, or a cellular or radio network), and which encodes a set of computer-readable instructions that, when executed by a processor of a device, cause the device to implement the techniques presented herein.

An example computer-readable medium that may be devised in these ways is illustrated in FIG. 6, wherein the implementation 600 comprises a computer-readable medium 602 (e.g., a CD-R, DVD-R, or a platter of a hard disk drive), on which is encoded computer-readable data 604. This computer-readable data 604 in turn comprises a set of computer instructions 606 configured to operate according to the principles set forth herein. As a first such example, the computer instructions 606 may cause the device 610 to utilize a method of exchanging notifications 210 of transit events 110 within a location 204 with other vehicles 104 in the location 206, such as the example method 300 of FIG. 3. As a second such example, the computer instructions 606 may provide a system for providing a transit service 202 to a set of vehicles 104 operating in a location 204, such as the example system 410 in the example scenario 400 of FIG. 4. As a third such example, the computer instructions 606 may provide a system for exchanging notifications 210 of transit events 110 within a location 204 with other vehicles 104 in the location 206, such as the example system 514 in the example scenario 500 of FIG. 5. Many such computer-readable media may be devised by those of ordinary skill in the art that are configured to operate in accordance with the techniques presented herein.

E. Variable Aspects

The techniques discussed herein may be devised with variations in many aspects, and some variations may present additional advantages and/or reduce disadvantages with respect to other variations of these and other techniques. Moreover, some variations may be implemented in combination, and some combinations may feature additional advantages and/or reduced disadvantages through synergistic cooperation. The variations may be incorporated in various embodiments (e.g., the example method 300 of FIG. 3; the example system 410 of FIG. 4; the example system 512 of FIG. 5; and the example computer-readable storage device 602 of FIG. 6) to confer individual and/or synergistic advantages upon such embodiments.

E1. Scenarios

A first aspect that may vary among embodiments of these techniques relates to the scenarios wherein such techniques may be utilized.

As a first variation of this first aspect, the techniques presented herein may be used with many types of vehicles 104, including automobiles, motorcycles, trucks, trains, buses, watercraft, aircraft, drones, and spacecraft. Such vehicles may be controlled by one or more humans, may be autonomous, or may involve a combination thereof, such as an autonomous automobile that can also be controlled by a human.

As a second variation of this first aspect, the techniques presented herein may be utilized to provide advise users 102 of events occurring in many types of areas 108 and/or locations 202, such as a roadway, highway, sidewalk, dirt or grass path, waterway, and airspace. Such areas 108 may also be defined statically, e.g., as the boundary of a municipality or a set of global positioning system (GPS) coordinates that define the boundaries of an area 108, may be defined dynamically, e.g., as an area 108 where an event such as a convention is occurring, or an area 108 where traffic congestion has been detected.

As a third variation of this first aspect, the techniques presented herein may be utilized to exchange notifications 210 about many types of transit events 110 occurring in an area 108, such as vehicular accidents; the formation of traffic congestion, such as due to high vehicle volume or construction; an obstruction, such as debris or wildlife; a hazardous condition in the location 204, such as a fire; and weather events, such as the formation of ice or flooding. Many such variations may arise within the set of scenarios in which the techniques presented herein may be utilized.

E2. Transit Event Detection

A second aspect that may vary among embodiments of these techniques involves the detection of the occurrence of the transit event 110, including information about the transit event 110 that may advise the other vehicles 104 as to how to respond to the transit event 110.

As a first variation of this second aspect, a vehicle device may receive a report of a transit event 110 directly from the user 102 within the vehicle 104. For example, the user 102 may initiate a voice report of an observed transit event 110, and the vehicle device may transmit the voice report of the user 102 to the transit service 202.

As a second variation of this second aspect, a vehicle device may evaluate telemetry of the vehicle 104 to detect a transit event 110. For example, telemetry indicating that the user 102 has engaged windshield wipers or fog lamps may indicate the presence of transit-affecting weather conditions in the location 204, and telemetry indicating an engagement of an anti-lock braking system in a particular location 204 (coupled with weather data indicating freezing weather) may indicate a transit event 110 involving the formation of ice on a road surface of in the location 204

FIG. 7 presents an illustration of an example scenario 700 featuring a third variation of this second aspect, involving a proximity sensor that generates proximity data indicating a proximity of the vehicle to a second vehicle, and a proximity data evaluator that evaluates the proximity data to identify the transit event 110. In this example scenario 700, a lane of a road occupied by a vehicle 104 of the user 102 is detected according to a proximity sensor 702 of the vehicle 104. Such proximity sensors 702 may utilize a variety of techniques for such detection, including visual evaluation of camera data; ranging data gathered by sonar, radar, and/or lidar detection; and/or electronic communication with other vehicles 104 in the location 204. In this example scenario 700, the vehicle 104 is equipped with a proximity sensor 702 that detects a proximity of the vehicle 104 with respect to other vehicles 104 operating in the location 204, such as a distance 704 between the vehicle 104 and another vehicle 104 that is ahead of and/or behind the vehicle 104 of the user 102; the relative speeds of the vehicles 104 ahead of and/or behind the user 102; and/or the rates of acceleration, braking, turning, and/or swerving by the user 102 and the drivers 106 of the other vehicles 104. The proximity sensor 702 may also detect information about vehicles 104 in other lanes of the road, such as the relative or absolute speeds of vehicles 104 in adjacent lanes and/or passing in the other direction of transit, and/or whether or not such vehicles 104 are passing 706 and/or are being passed by the vehicle 104. Moreover, such proximity data may be evaluated to detect a transit event 110. As a first such example, the proximity sensor 702 may detect one or more vehicles 104 that are stationary in an adjacent lane, in the median of the road, and/or off to the side of the road, may indicate the occurrence of a vehicular accident and position thereof in the location 204. As a second such example, the proximity sensor 702 may detect sudden changes in the proximity of the vehicles 104 indicating a transit event 110, such as a rapid deceleration of a vehicle 104 behind the vehicle 104 of the user 102 that indicates a collision. The vehicle device 708 may utilize the proximity sensor 704 to detect such transit events 110, and may send a notification 208 of the transit events 110 to the transit service 202.

FIG. 8 presents an illustration of example scenarios featuring a fourth set of variations of this second aspect, wherein a transit event 110 is detected by machine vision techniques 808. As a first example scenario 802, a vehicle device 708 on board the vehicle 104 may include and/or be in communication with a forward-mounted camera 802 that captures a forward-facing image 804 (e.g., through a windshield 806 of the vehicle 104). A machine vision technique 808, such as an object recognition algorithm, may be applied to the image 804, such as an object recognition technique that recognizes vehicles 104; extrapolates their positions within the location 204, and/or details such as their directions, speeds, and acceleration; and, by modeling their positions, identifies that a collision has occurred. A second machine vision technique 808 may be applied that utilizes a line detection algorithm to detect visible lines of the road that indicate lanes, including a current lane of the vehicle 104 of the user 102. The position of the vehicle 104 on the road may therefore be extrapolated by the machine vision technique 808, and this information may be utilized to provide additional information about the transit event 110 (e.g., which lane(s) the transit event 110 affects) and/or to adjust the navigation of the vehicle 104 and/or advise the user 102 (e.g., determining whether the current lane of the vehicle 104 avoids or is obstructed by the transit event 110). Alternatively or additionally, other machine vision techniques may be applied to the image 804 to about the transit event 110, such as object recognition to detect and optionally count a number of visible vehicles 104 ahead of the vehicle 104 of the user 102 in the respective lanes as a measurement of traffic congestion, and/or visual sizing machine vision techniques that estimate a distance of vehicles 104 ahead of the vehicle 104 of the user 102. As a second example scenario 810, a downward-facing camera 802 may capture a downward-facing image 804 of the location 204; an object recognition algorithm may be applied to detect objects that are visible on the surface of the road and that may indicate a transit event 110, such as ice, water, debris, or potholes; and a line detection machine vision technique 808 may be utilized to detect the visible lines indicating the lanes of the road, and/or the current lane that is currently occupied by the vehicle 104 of the user 102. Many such techniques may be utilized to detect and describe transit events 110 occurring within the location 204 of the vehicle 104 for reporting to the transit service 202 in accordance with the techniques presented herein.

E3. Exchange Protocol

A third aspect that may vary among embodiments of the techniques presented herein involves the manner of exchanging notifications 210 of transit events 110 among the vehicles 104 and the transit service 202.

As a first variation of this third aspect, vehicle devices and travel service 202 may communicate through a wide range of communication channels, such as electromagnetic wave transmissions at various frequencies. Such communication channels may also be utilized to exchange notifications 210 encoded in various ways, such as a human-receivable voice or tone; a human-readable message, such as text, images, and/or video; encoded data that describes the transit event 110, such as an extensible markup language (XML) providing fields that identify properties of the transit event 110 such as its precise location, type, and severity; and/or encoded data that provides instructions for autonomous control of a vehicle navigation system, such as instructions to engage a braking system to slow or halt the vehicle 104, and/or instructions to re-route the transit of the vehicle 104 through an alternative area. Many such communications protocols may be utilized to deliver such notifications 210 over the selected messaging channels, such as messages exchanged using a variant of the hypertext transport protocol (HTTP), including a websockets interface. As one such example, a vehicle communicator 406 of a server 402 providing the travel service 202 may comprise an internet connection that communicates with vehicle devices through the internet using a websocket protocol. A vehicle area group manager 412 may, in addition to adding a vehicle 104 to a vehicle area group 206, allocate a websocket to communicate with the vehicle 104 through the internet using the websocket protocol; and the transit event broadcaster 414 may broadcast the notification of the transit event 110 to the respective vehicles 104 through the respective websockets. Similarly, the transit service communicator 508 of a vehicle 104 may further comprise an internet connection through which the transit service communicator 508 communicates with the transit service 202 using a websocket protocol, and the local event notifier 518 may receive the notification 210 of the transit event 110 from the transit service 202 through a websocket of the websocket protocol that has been allocated to communicate with the transit service 202. The selection of a protocol such as websockets may enable further advantages, such as a reduced reliance on ping or keepalive messages to maintain the communication channel; as a result, the communication resources (e.g., radiofrequency bandwidth) may be conserved for the actual exchange of notifications 210 of transit events 110, which may also reduce the latency in the delivery of such notifications 210, and the scalability to support broadcasting to a large number of vehicles 104 in a particular location 204 with reduced interference. Websockets may also be advantageous due to the greater incidence of interruption of connectivity of vehicles 104 in transit, since ephemeral lapses in connectivity may not necessitate the exchange of network communication, but may be tolerated as part of the transit service 202.

As a second variation of this third aspect, many mechanisms may be utilized to associated vehicles 104 with vehicle area groups 206. As one such example, a transit service 202 may, upon receiving from the vehicle a first location 204, determine whether a vehicle area group 206 exists for the first location 204, and upon determining that a vehicle area group 206 does not exist for the first location 204, create a vehicle area group 206 for the first location 204. The transit service 202 may also, upon receiving from the vehicle 104 a second location 204 of the vehicle 204 (e.g., an updated global positioning service (GPS) coordinate), determine whether the second location 204 is also associated with the vehicle area group 206; and upon determining that the second location 204 is not associated with the vehicle area group 206, remove the vehicle 104 from the vehicle area group 206 for the first location 204 (e.g., transferring the association of the vehicle 104 from the first vehicle area group 206 for the first location 204 to a second vehicle area group 206 for the second location 204).

FIG. 9 presents an illustration of an example scenario 900 featuring a third set of variations of this third aspect involving the broadcasting of various notifications 208 of transit events 110 for a location 204. In this example scenario 900, in addition to the transit service 202 receiving notifications 208 from vehicles 104 that are enrolled in the transit service 202 and broadcasting such notifications 208 to the other vehicles 104 of the vehicle area group 206 that are also enrolled in the transit service 202, the transit service 202 may be utilized to retransmit notifications 208 generated by other services, and vice versa.

As a first such example, a vehicle device 706 may further comprise a local transit event rebroadcaster that locally rebroadcasts the notification 206 of the transit event 110 over a localized broadcast messaging channel. For example, after detecting a transit event 210 and transmitting the notification 208, and/or after receiving a notification 210 from the transit service 202, a vehicle device 2706 may utilize a transmitter 116 broadcast the notification 208 using a local broadcast messaging channel, such as a local, low-power radiofrequency (RF) broadcast, or a directed vehicle-to-vehicle communication channel. A receiver 120 within a second vehicle 104 that is not enrolled in the transit service 202, and/or that is enrolled but that is not in communication with the transit service 202 due to a temporary communication interruption, may therefore receive the local broadcast.

As a second such example, a localized broadcast channel monitor may be utilized to monitor a localized broadcast messaging channel, such as broadcasts by a regional broadcast tower 112 (e.g., a traffic message channel (TMS) broadcaster), and may retransmit notifications 210 of transit events 110 received through such a localized broadcast messaging channel to the transit service 202 for rebroadcasting to the other vehicles 104 of the vehicle area group 206 for the location 204 involved in the transit event 110. As another such variation, the transit service may remotely monitor sources of information about transit events 110, such as traffic message channel (TMS) information provided over the internet, and may broadcast notifications 210 of transit events 110 according to the vehicle area groups 206 for the locations 204 involved in the transit events 110. Such broadcasting may enable delivery of the localized broadcast message to other vehicles 104 that are not monitoring the localized broadcast messaging channel, but that are in communication with the transit service 202. Conversely, the transit service 202 and/or the vehicle device 706 may also provide information to other services for transmission via localized broadcast messaging channels. For example, upon receiving a notification 208 from a vehicle 104 in a location 204 of a transit event 110, the transit service 202 may, in addition to broadcasting a notification 210 to the vehicles 104 of the vehicle area group 206, transmit the notification 210 to the regional broadcast tower 112 for regional rebroadcast. Alternatively, the vehicle device 706 may transmit the notification 208 to the to the regional broadcast tower 112 for regional rebroadcast. Such rebroadcasting techniques may coordinate the exchange of notifications 210 among the vehicles 104 enrolled in the transit service 202 with the exchange of notifications 210 among other vehicles 104 that are not enrolled in the transit service 202, and/or that have lost communication with the transit service 202.

FIG. 10 presents an illustration of an example scenario 1000 featuring further variations of this third aspect involving the broadcasting of various notifications 208 of transit events 110 for various locations 204. In this example scenario 1000, in addition to the transit service 202 receiving notifications 208 from vehicles 104 that are enrolled in the transit service 202 and broadcasting such notifications 208 to the other vehicles 104 of the vehicle area group 206 in the same vehicle area group 206 for the same location 204, the transit service 202 may also determine other recipients of the information to which the notification 210 of the transit event 110 may apply.

As a fourth variation of this third aspect presented in FIG. 10, the transit service 202 receives a notification 208 of a multi-vehicle accident in a particular location 204, and, in addition to identifying the vehicles 104 within the vehicle area group 206 for the third location 204, may evaluate a second location 204 that may also be affected by the transit event 110, such as a distant stretch of the road that approaches the site of the transit event 110; an entrance ramp of a nearby road that leads to the transit event 110; or a second road that passes over or under the site of the transit event 110. The transit service 202 may determine whether the transit event 110 applies to the vehicles 104 of the second location 204, and may broadcast the notification 210 to the vehicles 104 in the vehicle area group 206 of the second location 204. For example, a weather-related event that is detected in a first location 204 may be projected as following a weather pattern (such as a wind direction) that is likely to affect a second location 204, and the transit service 202 may broadcast the notification 210 to the vehicles 104 in the vehicle area group 206 for the second location 204.

As a fifth variation of this third aspect, the notification 210 may be updated to reflect a recommendation to the vehicles 104, including the user 104 and the other drivers 106, as to how to respond to the transit event 110. For example, the second location 204 features a detour option 1002 for avoiding the location of the transit event 110, such as an exit ramp, an alternate route, or a second lane of a road that is not affected by the transit event 110 that impacts a first lane of the road. The transit service 220 may therefore add, to the notification 210 broadcast to the vehicles 104 of the vehicle area group 206, a recommendation 1004 to take the detour option 1002 to avoid the location 204 of the transit event 110.

As a sixth variation of this third aspect presented in FIG. 10, the transit service 202 may be configured to notify first responders as to the occurrence of a transit event 110, where such first responders provide a first response service relating to the transit event 110 for the location 204. For example, the transit service 202 may evaluate the information about the transit event 110 and may determine whether police, fire control personnel, medical personnel, tow trucks, or mechanics are to be directed to the location 204 of the transit event 110. The transit service 202 may therefore generate a notification 1006 to the first responders 1008, and may transmit the notification 1006 of the transit event 110 to the first responders 1008.

As a seventh variation of this third aspect, the transit service 202 may comprise a transit event verifier that endeavors to verify the transit events 110 reported by respective vehicles 104. For example, a transit event 110 involving a sudden braking incident by a vehicle 104 may indicate a transit event 110 such as an accident or ice, for which a notification 210 of the transit event 110 is to broadcast. However, the sudden braking may also indicate a transient event, such as a brief encounter with wildlife, or a vehicle or driver error, such as accidentally activating the brakes or misperceiving the presence of a vehicle in a nearby lane. Before broadcasting the notification 210, the transit service 202 may endeavor to verify the transit event 110 by identifying a second vehicle 104 of the vehicle area group 206 that is capable of verifying the transit event 110, and transmitting to the second vehicle 104 a request to verify the transit event 110 (e.g., by asking the driver 106 of the second vehicle 104 to confirm or refute the transit event 110, and/or by utilizing sensors of the second vehicle 104). The broadcasting of the notification 210 may be contingent upon first receiving a verification of the transit event 110 from the second vehicle 104.

As an eighth variation of this third aspect, before broadcasting a notification 210 to other vehicles 104 of a vehicle area group 206, the transit service 202 may utilize various techniques to anonymize the vehicle 104 that transmitted the notification 208 of the the transit event 110. For example, the transit service 202 may extrapolate the GPS coordinate transmitted by the vehicle 104 to the GPS coordinate of the transit event 110, and may include the latter GPS coordinate but not the former GPS coordinate that identifies which vehicle 104 transmitted the transit event 110. As another such example, where the notification 210 includes an image or voice recording of the transit event 110 captured by the vehicle 104 and/or the user 102, such as the user's name or a vehicle identifier of the vehicle 104 (e.g., the license plate), the transit service 202 may remove identifying features of such media before broadcast to the other vehicles 104 of the vehicle area group 206. Many such techniques may be included in the exchange of notifications 210 of transit events 110 in accordance with the techniques presented herein.

E4. Utilizing Transit Event Notification

A fifth aspect that may vary among embodiments of the techniques presented herein involves the manner of utilizing a transit event during the transit of the vehicle 104, such as advising a user 102 of the occurrence and details of a transit event 110.

As a first variation of this fourth aspect, information about the transit event 110 may be described to the user 102 in a variety of ways. As a first such example, the transit event 110 may be described in absolute terms (e.g., “warning: accident at northbound 14 kilometer mark”) or in relative terms (e.g., “warning: accident one kilometer ahead”), and may include a recommendation to the use 102 to adjust the control of the vehicle 104 (e.g., “reduce speed by 10 kph” or “engage fog lamps”). As a second such example, the device 202 may or may not explain the basis of a recommendation responsive to the transit event 110, e.g., why the user 102 is advised to choose an alternate route or lane of a road. Moreover, if the transit event 110 does not result in a recommendation to the user 102 to do anything else (e.g., if the safest path past a vehicular accident is the lane that the vehicle 104 currently occupies), a vehicle device 708 may either present the recommendation (e.g., “recommendation: maintain current lane”), or may defer such recommendation until detecting that the user 102 is considering transitioning to a different lane (e.g., upon detecting the user's activation of a turn signal). As still another example, the transit of the vehicle 104 may be controlled by a vehicle control system according to a driving behavior profile, and the transit event 110 may prompt the vehicle 104 to the driving behavior profile of the vehicle control system in response to the transit event 110 (e.g., reducing a cruise-control speed of the vehicle 104, engaging a braking system, and/or adjusting a route for the transit of the vehicle 104 to choose an alternative route that avoids the transit event 110).

FIG. 11 presents an illustration of a set of exemplary scenarios 1100 whereby a vehicle device 708 may notify the user 102 about a transit event 110. As a second variation 1102 of this fifth aspect, a visual and/or audial indicator may be presented to the user 102 by the vehicle device 708 and/or vehicle 104, such as a light on the dashboard of the vehicle 104 or an audio or voice cue 1104 prompting the user to select a particular lane 1112 to avoid the transit event 110. As a third variation 1106 of this fifth aspect, a visual indicator 1110 may be presented on a window 1108 of the vehicle 104, and, optionally, may be presented at a selected location 1114 on the window 1108 that correlates the visual indicator 1110 with the location 1112 of the transit event 110 through the window 1108 from the perspective of the user 102 (e.g., presenting a visual arrow and/or highlighting the location of the transit event 110 when viewed through the window 1108 by the user 102). As a fourth variation 1114 of this fifth aspect, the user 102 may wear one or more wearable devices while operating the vehicle 104, such as a pair of eyeglasses 1116 or a wristwatch 1118. The presentation of the notification 210 of the transit event 110 may be achieved through such wearable devices, e.g., by presenting a visual indicator 1120 within the viewable region of the eyeglasses 1116 worn by the user 102, and/or issuing a vibration alert 1122 through the wristwatch 1118 of the user 102 to indicate the location of the transit event 110 (e.g., flashing a leftward visual indicator 1120 or a vibration alert 1122 on the user's left wrist to draw the user's attention to the left lane where a transit event 110 has occurred). Many such techniques may be utilized to present to the user 102 the notification 210 of the transit event 110 in accordance with the techniques presented herein.

F. Computing Environment

FIG. 12 and the following discussion provide a brief, general description of a suitable computing environment to implement embodiments of one or more of the provisions set forth herein. The operating environment of FIG. 12 is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the operating environment. Example computing devices include, but are not limited to, personal computers, server computers, hand-held or laptop devices, mobile devices (such as mobile phones, Personal Digital Assistants (PDAs), media players, and the like), multiprocessor systems, consumer electronics, mini computers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

Although not required, embodiments are described in the general context of “computer readable instructions” being executed by one or more computing devices. Computer readable instructions may be distributed via computer readable media (discussed below). Computer readable instructions may be implemented as program modules, such as functions, objects, Application Programming Interfaces (APIs), data structures, and the like, that perform particular tasks or implement particular abstract data types. Typically, the functionality of the computer readable instructions may be combined or distributed as desired in various environments.

FIG. 12 illustrates an example of a system 1200 comprising a computing device 1202 configured to implement one or more embodiments provided herein. In one configuration, computing device 1202 includes at least one processing unit 1206 and memory 1208. Depending on the exact configuration and type of computing device, memory 1208 may be volatile (such as RAM, for example), non-volatile (such as ROM, flash memory, etc., for example) or some combination of the two. This configuration is illustrated in FIG. 12 by dashed line 1204.

In other embodiments, device 1202 may include additional features and/or functionality. For example, device 1202 may also include additional storage (e.g., removable and/or non-removable) including, but not limited to, magnetic storage, optical storage, and the like. Such additional storage is illustrated in FIG. 12 by storage 1210. In one embodiment, computer readable instructions to implement one or more embodiments provided herein may be in storage 1210. Storage 1210 may also store other computer readable instructions to implement an operating system, an application program, and the like. Computer readable instructions may be loaded in memory 1208 for execution by processing unit 1206, for example.

The term “computer readable media” as used herein includes computer storage media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions or other data. Memory 1208 and storage 1210 are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by device 1202. Any such computer storage media may be part of device 1202.

Device 1202 may also include communication connection(s) 1216 that allows device 1202 to communicate with other devices. Communication connection(s) 1216 may include, but is not limited to, a modem, a Network Interface Card (NIC), an integrated network interface, a radio frequency transmitter/receiver, an infrared port, a USB connection, or other interfaces for connecting computing device 1202 to other computing devices. Communication connection(s) 1216 may include a wired connection or a wireless connection. Communication connection(s) 1216 may transmit and/or receive communication media.

The term “computer readable media” may include communication media. Communication media typically embodies computer readable instructions or other data in a “modulated data signal” such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” may include a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.

Device 1202 may include input device(s) 1214 such as keyboard, mouse, pen, voice input device, touch input device, infrared cameras, video input devices, and/or any other input device. Output device(s) 1212 such as one or more displays, speakers, printers, and/or any other output device may also be included in device 1202. Input device(s) 1214 and output device(s) 1212 may be connected to device 1202 via a wired connection, wireless connection, or any combination thereof. In one embodiment, an input device or an output device from another computing device may be used as input device(s) 1214 or output device(s) 1212 for computing device 1202.

Components of computing device 1202 may be connected by various interconnects, such as a bus. Such interconnects may include a Peripheral Component Interconnect (PCI), such as PCI Express, a Universal Serial Bus (USB), firewire (IEEE 1394), an optical bus structure, and the like. In another embodiment, components of computing device 1202 may be interconnected by a network. For example, memory 1208 may be comprised of multiple physical memory units located in different physical locations interconnected by a network.

Those skilled in the art will realize that storage devices utilized to store computer readable instructions may be distributed across a network. For example, a computing device 1220 accessible via network 1218 may store computer readable instructions to implement one or more embodiments provided herein. Computing device 1202 may access computing device 1220 and download a part or all of the computer readable instructions for execution. Alternatively, computing device 1202 may download pieces of the computer readable instructions, as needed, or some instructions may be executed at computing device 1202 and some at computing device 1220.

G. Usage of Terms

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

As used in this application, the terms “component,” “module,” “system”, “interface”, and the like are generally intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

Furthermore, the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.

Various operations of embodiments are provided herein. In one embodiment, one or more of the operations described may constitute computer readable instructions stored on one or more computer readable media, which if executed by a computing device, will cause the computing device to perform the operations described. The order in which some or all of the operations are described should not be construed as to imply that these operations are necessarily order dependent. Alternative ordering will be appreciated by one skilled in the art having the benefit of this description. Further, it will be understood that not all operations are necessarily present in each embodiment provided herein.

Moreover, the word “example” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “example” is not necessarily to be construed as advantageous over other aspects or designs. Rather, use of the word example is intended to present concepts in a concrete fashion. As used in this application, the term “or ” is intended to mean an inclusive “or ” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an ” as used in this application and the appended claims may generally be construed to mean one or more unless specified otherwise or clear from context to be directed to a singular form.

Also, although the disclosure has been shown and described with respect to one or more implementations, equivalent alterations and modifications will occur to others skilled in the art based upon a reading and understanding of this specification and the annexed drawings. The disclosure includes all such modifications and alterations and is limited only by the scope of the following claims. In particular regard to the various functions performed by the above described components (e.g., elements, resources, etc.), the terms used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated example implementations of the disclosure. In addition, while a particular feature of the disclosure may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms “includes”, “having”, “has”, “with”, or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising.” 

What is claimed is:
 1. A method of broadcasting localized transit events detected during transit of a vehicle, the method involving a device having a processor and in communication with a transit service and comprising: executing, on the processor, instructions that cause the device to: detect a location of the vehicle; transmit the location to the transit service to add the vehicle to a vehicle area group for the location; upon detecting a transit event in the location of the vehicle, transmit the transit event to the transit service for broadcasting to other vehicles of the vehicle area group; and upon receiving from the transit service a notification of a transit event for the vehicle area group, utilize the notification in the transit of the vehicle.
 2. The method of claim 1, wherein utilizing the notification in the transit of the vehicle further comprises: presenting the notification to a user within the vehicle.
 3. The method of claim 2, wherein: the vehicle further comprises a window; and presenting the notification to the user further comprises: displaying the notification on the window of the vehicle.
 4. The method of claim 1, wherein: the transit event relates to a route of the transit of the vehicle; and utilizing the notification in the transit of the vehicle further comprises: adjusting the route of the vehicle in response to the transit event.
 5. The method of claim 1, wherein: the transit of the vehicle is controlled by a vehicle control system according to a driving behavior profile; and utilizing the notification in the transit of the vehicle further comprises: adjusting the driving behavior profile of the vehicle control system in response to the transit event.
 6. A server that provides a transit service to vehicles, the server comprising: a processor; a vehicle communicator that communicates with the vehicles; and a memory storing instructions that, when executed by the processor, provide a system comprising: a vehicle area group manager that, upon receiving a location of a vehicle, adds the vehicle to a vehicle area group for the location; and a transit event broadcaster that, upon receiving, from a vehicle, a transit event for the location: identifies at least one other vehicle of the vehicle area group; and broadcasts to the at least one other vehicle of the vehicle area group a notification of the transit event.
 7. The server of claim 6, wherein the system further comprises: a vehicle anonymizer that: identifies, in the notification of the transit event, a vehicle identifier that identifies the vehicle that transmitted the transit event; and removes the vehicle identifier from the notification of the transit event.
 8. The server of claim 6, wherein the server adds the vehicle to the vehicle area group by: upon receiving from the vehicle a first location: determining whether a vehicle area group exists for the first location; upon determining that a vehicle area group does not exist for the first location, creating a vehicle area group for the first location; and upon receiving from the vehicle a second location: determining whether the second location is associated with the vehicle area group; and upon determining that the second location is not associated with the vehicle area group, removing the vehicle from the vehicle area group for the first location.
 9. The server of claim 6, wherein the server further comprises: a vehicle area group evaluator that, upon receiving a notification of a transit event for the location: identifies a second location that is affected by the transit event; identifies at least one vehicle of a second vehicle area group for the second location; and broadcasts the notification of the transit event to the at least one vehicle of the second vehicle area group.
 10. The server of claim 9, wherein: the second location features a detour option for avoiding the location of the transit event; and broadcasting the notification of the transit event to the second vehicle area group further comprises: adding to the notification a recommendation to take the detour option to avoid the location of the transit event.
 11. The server of claim 9, wherein the system further comprises: a first responder notifier that: identifies a first responder that provides a first response service relating to the transit event for the location; and transmits the notification of the transit event to the first responder.
 12. The server of claim 6, wherein the system further comprises: a transit event verifier that, upon receiving the notification of the transit event: identifies a second vehicle of the vehicle area group that is capable of verifying the transit event, and transmits to the second vehicle a request to verify the transit event; and broadcasting the notification to the vehicle area group further comprises: broadcasting the notification of the transit event to the at least one other vehicle of the vehicle area group only after receiving a verification of the transit event from the second vehicle.
 13. The server of claim 6, wherein: the vehicle communicator comprises an internet connection that communicates with a device of the vehicle through the internet using a websocket protocol; the vehicle area group manager adds the vehicle to the vehicle area group by allocating a websocket to communicate with the vehicle through the internet using the websocket protocol; and the transit event broadcaster broadcasts the notification of the transit event to the respective at least one other vehicle through the websocket for the other vehicle.
 14. A vehicle device that broadcasts localized transit events detected during transit of a vehicle, the vehicle device comprising: a processor; a location detector that detects a location of the vehicle; a transit service communicator that communicates with a transit service; a transit event detector that detects a transit event in the location of the vehicle; and a memory storing instructions that, when executed on the processor, cause the vehicle device to provide a system comprising: a transit service interface that: transmits the location, via the transit service communicator, to add the vehicle to a vehicle area group for the location, and transmits, via the transit service communicator, the transit event for broadcasting to other vehicles of the vehicle area group; and a local event notifier that, upon receiving from the transit service a notification of a transit event for the vehicle area group, utilizes the notification in the transit of the vehicle.
 15. The vehicle device of claim 14, wherein: the transit service communicator further comprises an internet connection through which the transit service communicator communicates with the transit service using a websocket protocol; and the local event notifier receives the notification from the transit service through a websocket of the websocket protocol allocated to communicate with the transit service.
 16. The vehicle device of claim 14, wherein the transit event detector further comprises: a proximity sensor that generates proximity data indicating a proximity of the vehicle to a second vehicle; and a proximity data evaluator that evaluates the proximity data to identify the transit event.
 17. The vehicle device of claim 14, wherein the transit event detector further comprises: a localized broadcast channel monitor that receives a notification of a localized transit event over a localized broadcast messaging channel.
 18. The vehicle device of claim 17, wherein the transit service interface transmits, via the transit service communicator, the notification of the localized transit event received over the localized broadcast messaging channel.
 19. The vehicle device of claim 14, wherein the system further comprises: a local transit event rebroadcaster that locally rebroadcasts the notification of the transit event over a localized broadcast messaging channel.
 20. The vehicle device of claim 14, wherein: the vehicle is in communication with a second vehicle of the location through a local vehicle communicator; and the system further comprises: a local transit event notifier that transmits the notification of the transit event to the second vehicle through the local vehicle communication. 